Subject: Re: Comments on cisco's scalability proposal (fwd)

From: [email-masked] (Ravi C. Periasamy)
Date: Thu, 27 Jul 1995 14:27:43 -0400

David,

Please see my response below.

Regards,
Ravi Periasamy,
[email-masked]

David Bryant/HQ/3Com wrote:
>
>I've read through the cisco proposal and have the following significant
>questions/comments:
>
>1). The proposal as currently submitted is clearly too ambiguous to understand

If you have questions about specific sections or features, I can explain
them. OR if you/others feel that the whole document is too ambiguous, I
can re-write it and re-post it.

>precisely what is being proposed.  Many sections contain options and choices
>which would alter other areas.  So the proposal as it stands does not
>provide a
>self-consistent description of the modified protocol.

Most of the features descibed are very simple and pretty much can be
implemented from the description given. In a few cases, I have proposed
more than one way of doing it. That was not to confuse people but to
give a choice, so we do the right thing, even if it means extra work for
me to change our implementation :-)

If you feel that such options are unnecessary, I can decide on one
of the options based on my knowledge of the system, and propose that.

I have added atleast a one line comment where the options change the
behaviour of other features.

>2). The proposal does not adequately address the issues of "base and towers".
>Which portions of the proposal are mandatory and which portions are optional?
>Which functions have dependencies on other functions?

Currently we (cisco) have implemented all of these features and can still
co-exist with other 1795 implementations. All these features could be taken
to be extensions, required mostly for large networks. But ofcourse it
depends on which one of the choices we pick.

>3). Interoperation with RFC 1795 nodes is not well addressed.  It is not clear
>that this proposal will work in the presence of RFC 1795 nodes.  This
>interrelationship must be further defined and all restrictions duly noted.
>Additionally, it should be a design objective to accomodate easy migration
>from
>RFC 1795 networks to DLSw networks with scalability enhancements.  It's not
>clear (one way or the other) whether the Border Peers proposal can do this.

All these extensions can (and does in our implementation) co-exist with
existing DLSw standard implementations. Some of the features proposed
could be implemented and used only if the 'other peer' has the same
feature implemented. Some of the other features have only a 'local'
significance and could be used irrespective of the other sides implementation.

Passive Peers, Peer-on-demand, and backup-peers all could be implemented
in such a way that, those features are useful even while interoperating
with a standard 1795 box.

For peer-costs to be fully useful, all peers in the list should have the
feature implemented. But it can co-exists with ones that do not have this
feature, for easy migration.

Border Peers, and Peer groups require the members of the group to be
'group enhanced'. If any of the peers in the peer list do not belong to
the group, or do not have the group enhancements, those peers cannot
use the peer group functionality. But they can still co-exist.

For example, when an explorer frames comes in from the LAN and needs to be
broadcast to ALL peers, the frame is sent as a relay frame to the border
peer and is also sent as usual (as stated in 1795) to other peers in the
peer list that do not belong to any group. That should cover co-existance
and migration.

>4). Handling POD Peers:
>It is not viable to select option 2 in which POD peers list the resources they
>can reach in the capabilities exchange with the exclusive flag.  The nature of
>stations available on a LAN will change over time and POD peers will not be
>able to relay this changed information.

That is correct. I made a mistake with that option. The peer that opens
the POD peer cannot effectively do that. Which will leave us with an
option to set the peer type with the POD specific information, if the
remote peer is known to be an enhanced peer. If the other side is not
an enhanced peer, just drop the frames that you do not want to handle it.
Even in the latter case, the situation will not be any worse than the
current method.

>5). Backup Peers
>I do not favor bringing down SSP-SSP connections when live circuits exist.  It
>will also be difficult to address traffic which does not flow on circuits such
>as NetBIOS datagrams and perhaps HPR traffic in the future.  The proposal does

I agree with your first point. But the backup peer is taken down only when
the primary peer connection is restored. So connectioless traffic flow is
not affected.

>as NetBIOS datagrams and perhaps HPR traffic in the future.  The proposal does
>not specify which SSP is responsible for bringing down the backup SSP-SSP
>connection.

The peer that opens up the backup peer should be responsible for taking it
down. For example Peer A has Peer B configured with Peer C as the backup of
Peer B. When Peer B comes back up, Peer A should be responsible to take
down Peer C. As you can see, as long as Peer C does not actively bring
up connection to peer A (either configured as passive, or just configured to
accept any connection request), Peer C need not even have support for
Peer On Demand.

>
>6). Peer Costs
>It's not clear to me the distinction between: "peer costs", "peer connection
>costs", and "path costs"

Peer cost is the cost of the DLSw entity. This is exchanged in CAPEX.
Path cost is the cost configured by the user for the particular peer
connection.

For example:
In Peer A configuration:
    Peer Cost 4.
    Peer B path cost 3.

Peer B Configuration:
    Peer Cost 4.

In the above case, the peer cost of 4 is sent by A to B is CAPEX. And B
marks the cost of A to be 4. But When B sends that cost to A, A over rides
that with the configured Path cost of B as 3.

>Use of this cost notion is also likely to effect the CANUREACH/ICANREACH
>protocols as it will likely be important to wait for all responses prior to
>choosing an SSP connection path for circuit setup.  And since the
>CANUREACH/ICANREACH protocol does not have the concept of a negative response
>(ICANTREACH), this introduces further complexities in resolving circuit setup
>to the appropriate SSP connection.

No. This does not affect the CUR/ICR sequence. You do not have to wait for
all peers to respond. When an ICR is received, DLSw could go ahead and
respond to the test frame that was received. Now one of several things
could happen.

1. We do not receive any more ICRs.
2. We receive other ICR for none is better than the one we already have.
3. We receive an ICR from a better peer BEFORE we start a circuit.
4. We receive an ICR from a better peer AFTER we start a circuit.

Case 1 and 2 are okay. By chance we have made the best choice.
Case 3 may be okay (depending upon implementation). Since we can use the
new information when we start the circuit.
In Case 4, we make a not-so-perfect decision for one (or a few) circuits,
which is no worse than how 1795 already handles it. But we get a great
chance of making a better decision for subsequent requests for the same
resouce, which is a lot better than the current method.

>
>7). Peer Groups & Border Peers
>It appears as though a Border Peer cannot have connections to an RFC 1795 (or
>prior) node.

Correct. A border peer for the peer group functionality cannot have an
RFC 1795 peer in the group.

>Use of multicasting introduces further migration complications in
>requiring all
>nodes to support IP multicasting of the same type (MOSPF, DVMRP, etc.).

Correct. But border peer/peer groups does not rely on IP multicasting
support. But if the necessary support is available, border peer can
use that to broadcast the frame, else can use the traditional method
or a combination of both.

>8). Peer on Demand
>Delays in SSP-SSP connection setup are very likely to cause problems with
>NetBIOS communications which are very time delay sensitive.  This may
>effectively negate the use of Peer on Demand in NetBIOS networks which is the
>primary environment for the Border Peer proposal (meshed SSP networks).

The time required to bring up a POD is an issue with netbios stations may
be high in certain cases. But it really depends on the implementation. We
have done some tests in the past to verify this and POD with NetBIOS seems
to work okay. I do not know of the complexity of the network used to test
this feature.

>9). Non-Meshed networks
>The proposal does not do anything to reduce TCP/IP overhead associated with
>configurations where many DLSw LANs must access a single data center.  This is
>the most common SNA configuration and as such deserves some measure of
>attention.
>
>David Bryant
>3Com Corp

Regards,
Ravi Periasamy,
[email-masked]